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ABSTRACT 


This  thesis  is  intended  to  provide  a  Navy  Logistician  with  an  overview  of 
computer  modeling  and  simulation  uses  and  management  within  the  Department  of 
the  Navy.  This  thesis  research  indicates  a  large  demand  for  models  and  simulations 
with  joint  applicability.  It  also  indicates  the  need  for  the  Navy  to  examine  modeling 
and  simulation  management  and  organization  to  ensure  economic  and  effective 
utilization.  With  decreasing  Department  of  Defense  budgets,  the  efficient 
management  of  this  critical  resource  and  capability  is  extremely  important.  The 
information  contained  in  this  thesis  will  be  of  value  for  a  Navy  logistician  in 
providing  knowledge  about  a  few  models  and  simulations  and  the  trend  towards 
joint  applicability. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Simulation  is  one  of  the  most  frequently  used  system 
analysis  methods.  There  are  a  number  of  reasons  for  this. 

First,  simulation  can  be  used  to  analyze  models  of  arbitrary 
complexity.  The  complexity  of  the  model  is  limited  only  by 
the  ability  of  the  modeler  and  the  methodology  to  represent 
the  system’s  complexity,  and  the  computer’s  capacity  to  load 
and  run  the  simulation  program.  The  investigator’ s  primary 
interest  might  be  to  experiment  with  the  system  model  in 
order  to  find  the  design  that  maximizes  one  or  more 
performance  measures,  or  simply  to  study  the  behavior  of 
the  system.  Experimenting  with  the  real  system  is  often  out 
of  the  question  because  of  the  cost  to  implement  system 
changes,  or  the  potential  danger  that  could  result  from  some 
policies  being  tested.  Often  the  modeling  effort  is  useful  in 
itself.  The  process  of  model  development  requires  the 
system  to  be  studied  and  understood  well.  This  study 
frequently  uncovers  problems  diat  were  unknown  or  not 
understood  before.  Relative  to  other  methodologies, 
simulation  can  carry  more  credibility  with  decision  makers. 

For  example,  an  animation,  which  is  a  visual  representation 
of  the  model,  can  be  used  to  demonstrate  that  the  model 
actually  approximates  system  performance.  Thus,  a 
simulation  feels  more  “real”  than  other  methods  for  system 
analysis.  (Alexopoulos  etal.,  1995) 

Computer  modeling  and  simulation  continues  to  take  on  increased  use  and  focus  in 
the  Department  of  Defense  (DoD).  But  now  with  reducing  force  levels  and  increasingly 
tight  fiscal  constraints  the  payoff  of  computer  modeling  and  simulation  is  being  seriously 
scrutinized.  On  June  1991  the  Defense  Modeling  and  Simulation  Office  (DMSO)  was 
established  by  the  Undersecretary  of  Defense  for  Acquisition.  In  addition  to  the 
promulgation  of  modeling  and  simulation  policy,  DMSO  was  to  promote  cooperation 
among  DoD  components  in  order  to  maximize  efficiency  and  effectiveness.  (MSIS,  1995, 
web) 


However,  it  appears  that  a  degree  of  dissatisfaction  with  the  management  of 
computer  modeling  and  simulation  exists  within  the  DoD.  Specifically,  Pentagon  officials 
cut  funding  for  the  DMSO  about  $  1 1  million  to  a  level  of  about  $52  million.  Funds  could 
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have  been  cut  to  as  low  as  $40  million.  While  no  programs  were  canceled  “in-depth 
reviews  of  all  priorities  are  continuing”.  A  defense  source  stated,  “we  need  to  go  back  and 
look  at  all  simulation  priorities.”  (Holzer,  1996,  p.l6) 

While  the  DoD  is  cutting  funding  to  the  main  computer  modeling  and  simulation 
office,  the  individual  military  departments  2ire  preparing  for  possible  congressional  budget 
attacks.  Army  Chief  of  Staff  Gen.  Dennis  Reimer  has  initiated  a  complete  internal  review  of 
modeling  and  simulation  funding.  The  Army  allocates  almost  two  percent  of  its 
discretionary  funding  to  computer  modeling  and  simulation.  This  computes  to  about  $710 
million  for  fiscal  year  1997.  “However  simulation  costs  are  rising  and  the  Army  is  still 
asking  for  the  same  levels  of  OPTEMPO  funding  today  as  we  have  in  the  past.”  Gen. 
Reimer  believes  that  Congress  will  find  fault  with  the  Army’s  investment  efforts  and  that 
justification  to  Congress  will  be  difficult.  This  will  result  more  than  likely  in  a  reduction  in 
funding.  (Sherman,  1995) 

Before  we  go  any  further,  we  must  define  a  model  and  a  simulation.  A  model  is  a 
representation  of  a  system  or  process.  A  simulation  is  the  implementation  of  a  model  over 
time.  For  the  logistician,  the  most  widely  used  model  among  all  the  military  services  is  the 
level-of-repair  analysis  (LORA).  With  more  emphasis  on  joint  operations  and  joint 
acquisitions  programs,  such  as  the  Joint  Strike  Fighter  Program  (JSPO,  it  is  important  (hat  a 
Navy  logistician  understand  the  level  of  repair  analysis  models  of  our  sister  services. 

Each  service  has  its  own  variation  of  LORA.  The  Army  now  uses  the 
Computerized  Optimization  Model  for  Predicting  and  Analyzing  Support  Structures 
(COMPASS).  This  model  replaced  the  optimum  supply  and  maintenance  model 
(OSAMM).  The  Navy  uses  the  Level  Of  Repair  Analysis  (LORA)  model  and  the  Air  Force 
uses  the  Network  Repair  Level  Analysis  (NRLA)  model.  As  a  Navy  logistician  it  is 
important  to  understand  the  similarities  and  differences  of  these  models. 
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B.  FOCUS  OF  THESIS 


In  this  thesis,  we  will  fcxjus  on  computer  modeling  and  simulation  uses  within  the 
DoD.  This  is  a  highly  complex  problem  that  is  gaining  increased  budgetary  focus.  We  will 
concentrate  on  some  uses  of  computer  modeling  and  simulation  in  the  DoD.  We  will  study 
DMSO  and  also  an  overview  of  the  modeling  and  simulation  structure  of  the  Navy.  Then 
we  will  look  at  other  Navy  computer  modeling  and  simulation  logistics  issues,  including  a 
joint  program  within  DoD  and  investigate  whether  the  management  organization  can  be 
applied  to  computer  modeling  and  simulation. 

C.  STRUCTURE  OF  THESIS 

Chapter  II  provides  an  overview  of  the  variations  of  LORA  used  by  each  military 
service.  Chapter  III  provides  an  overview  of  the  Defense  Modeling  and  Simulation  Office 
(DMSO).  It  explores  the  organization,  goals  and  future  of  the  office.  Additionally,  this 
chapter  provides  and  overview  of  the  modeling  and  simulation  management  structure  of  the 
Navy.  Chapter  IV  looks  at  a  couple  of  issues  within  the  Department  of  the  Navy  with 
regard  to  computer  modeling  and  simulation.  Chapter  V  highlights  a  few  computer  models 
in  the  area  of  joint  logistics.  Chapter  VI  provides  the  summary,  conclusions  and 
recommendations. 
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II.  LEVEL  OF  REPAIR  ANALYSIS  (LORA)  MODELS 

The  purpose  of  this  chapter  is  to  examine  LORA  models  being  used  by  the  different 

services.  To  perform  the  function  of  level  of  repair  analysis,  the  Army,  Air  Force,  and  the 

Navy  each  uses  a  computer  based,  mathematical  level  of  repair  model.  With  decreasing 

defense  budgets,  it  is  highly  likely  that  in  a  joint  program,  one  would  come  into  contact 

with  a  model  from  one  of  the  other  services.  It  is  very  important  for  military  logisticians  to 

be  familiar  with  the  similarities  and  differences  of  these  math  models. 

A.  U.S.  ARMY;  COMPUTERIZED  OPTIMIZATION  MODEL  FOR 
PREDICTING  AND  ANALYZING  SUPPORT  STRUCTURES  (COMPASS) 

1.  Background 

The  development  of  COMPASS  can  be  traced  back  to  1987.  ‘The  concept  for 
developing  COMPASS  was  originally  conceived  by  a  LORA  subgroup  at  the  LSA 
Technical  Working  Group  (TWG)  Meeting  Number  6,  9-13  Feb  87.  During  this  meeting, 
the  subgroup  determined  models  that  were  being  used  by  the  Army  community  for 
conducting  LORA  did  not  satisfy  their  needs.”  (USAMC,  1994)  Thus  a  new  program  was 
initiated  to  design  and  develop  a  new  math  model.  COMPASS  was  this  new  math  model, 
with  an  initial  goal  of  completion  of  between  3  and  10  years.  The  mathematical  equations 
used  in  Optimum  Supply  and  Maintenance  Model  (OSAMM)  were  used  as  the  “basis  in  the 
development  of  COMPASS.”  (USAMC,  1994)  COMPASS’ s  purpose  was  to  conduct 
system-level  LORA  previously  conducted  by  OSAMM  and  Logistics  Analysis  Model 
(LOGAM)  and  to  operate  on  a  personal  computer  (pc)  vice  a  mainframe  computer.  Given 
the  technological  advances  in  computer’s,  the  result  would  be  a  program  just  as  if  not  more 
powerful  than  its  predecessors. 
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2.  Model  Overview 


a.  COMPASS  Products 

-  “Repair  level  decision  for  each  item  under  analysis.” 

-  “Cost  and  allocation  of  manpower  and  support  equipment  required  to 
repair  the  system.” 

-  “Is  it  economical  to  develop  test  program  sets  (TPS)?” 

-  “Is  it  economical  to  screen  an  item  before  it  is  evacuated  to  another 
maintenance  echelon  for  repair?” 

-  “Cost  of  initial  and  replenishment  spares  over  the  life  of  the  system.” 

-  “Overall  costs  associated  with  transportation,  cataloging,  training, 
technical  manuals,  etc.” 

-  “Design  for  discard  candidates.” 

-  “  Source  for  development  of  the  MAC  and  Source,  Maintenance,  and 
Recoverability  (SMR)  code.”  (USAMC,  1994) 

b.  Model  Highlights 

-  “Maintenance  concept  decisions  are  made  within  COMPASS  by 
considering  all  maintenance  and  supply  related  functions  concurrently.” 

-  Supply  algorithms  used  in  COMPASS  have  been  taken  from  the  Selected 
Essential-Item  Stockage  Availability  Method  (SESAME) 

-  “In  order  to  determine  the  least  cost  maintenance  alternative  for  each  item, 
COMPASS  formulates  the  problem  in  a  linear  programming  form.” 

-  If  a  user  identifies  an  item  in  the  input  file,  COMPASS  will  determine  “the 
most  economical  location  where  the  item  should  be  removed  and 
replaced,  repaired  or  discarded.” 
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-  The  user  identifies  the  manpower  and  support  equipment  required  to  repair 
the  items.  COMPASS  determines  the  optimal  location  for  the  manpower 
and  support  equipment. 

-  The  user  identifies  lowest  echelon  where  the  repair  equipment  and 
repairperson  is  authorized  and  the  lowest  echelon  where  they  are  common. 
COMPASS  computes  the  charges. 

-“Cost  elements  within  COMPASS  are  a  mixture  of  one  time  and  annual 
recurring  cost.” 

-  COMPASS  determines  the  most  economical  location  of  repair 
(government  or  contractor) 

-  COMPASS  considers  basically  6  maintenance  locations; 

-  organizational  (org) 

-  direct  support  (ds) 

-  general  support  (gs) 

-  depot 

-  contractor 

-  discard 

c.  Model  Outputs 

After  the  user  has  completed  the  building  of  the  data  file,  there  are  three 
choices  for  execution.  They  are  front-end  analysis,  optimizer,  and  evaluator.  ‘The  front- 
end  analysis  program  should  always  be  run  before  the  optimizer  or  evaluator  are  run.” 
(USAMC,  1994)  The  front-end  analysis  program  identifies  all  errors  in  the  input  file  and 
can  also  provide  the  user  with  a  copy  of  all  the  data  contained  in  the  file.  The  optimizer  and 
the  evaluator  will  not  run  if  there  are  any  errors  present.  The  optimizer  program  determines 
“the  optimum  (least  cost)  maintenance  concept  for  the  weapon  system.”  (USAMC,  1994) 
The  program  will  provide  the  optimum  maintenance  concept  for  each  item  the  user  listed  in 
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the  input  file.  It  will  also  include  the  computation  for  life  cycle  and  support  cost  for  the 

maintenance  concept  that  was  selected.  The  evaluator  program  is  “used  to  determine 

maintenance  and  support  costs  based  on  a  user-defined  maintenance  concept.”  (USAMC, 

1994)  The  user  runs  this  program  to  conduct  sensitivity  analysis  and  to  determine  the  effect 

on  life  cycle  costs  if  a  maintenance  concept  is  changed  or  modified. 

B.  U.S.  AIR  FORCE:  NETWORK  REPAIR  LEVEL  ANALYSIS  MODEL 
(NRLA) 

1.  Model  Highlights 

-  “NRLA  is  the  preferred  means  of  performing  LORA.”  It  performs  LORA  for 
line  replaceable  units  (LRU)  and  shop  replaceable  units  (SRU)  (ASC/ALTD,  1995) 

-  The  model  does  not  include  all  life  cycle  cost  elements.  It  only  includes  those  that 
have  a  direct  impact  on  repair  level  decisions.  Therefore,  it  is  not  a 
comprehensive  life  cycle  cost  model. 

-  The  model  chooses  between  three  levels  of  repair:  intermediate  level  repair, 
depot  level  repair,  and  discard  -at-failure. 

-  The  model  does  not  attempt  to  allocate  support  equipment  costs  to  individual 
items. 

2.  Model  Assumptions 

-  ‘The  logistics  system  is  composed  of  some  number  of  operational  locations 
(bases)  and  some  number  of  centralized  repair  facilities  (depots)  supporting  the 
bases.”  (ASC/ALTD,  1995)  The  base  has  two  repair  facilities,  flight  line  and  base 
shop  (intermediate).  The  model  assumes  all  bases  send  repairables  to  the  same 
depot.  Therefore  the  model  assumes  only  one  depot. 

-  “Intermediate  level  maintenance  systems  data  (available  work  time  per  man,  labor 
rate,  and  turnover  rate)  are  assumed  equal  for  all  intermediate  locations  and  all  types 
of  repair  tasks. ’’(ASC/ALTD,  1995) 
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-  “Supply  system  data  factors  are  assumed  to  be  constant  for  all  LRU’s  and  SRU’s 
being  analyzed.”  (ASC/ALTD,  1995) 

-  “Only  one  set  of  technical  data  is  purchased  from  the  contractor.”  (ASC/ALTD, 
1995) 

-  “Scheduled  maintenance  actions  are  not  specifically  considered  by  the  model.” 
(ASC/ALTD,  1995) 

-  ‘The  model  explicitly  evaluates  each  LRU  failure  mode  for  a  repair  level 
decision.”  (ASC/ALTD,  1995) 

-  The  model  only  evaluates  the  principal  SRU  for  repair  level  decisions. 

-  The  depot  stock  of  SRU’s  is  computed  to  enable  the  depot  to  resupply  the 
intermediate  level  when  SRU’s  are  sent  to  depot  for  repair. 

3.  Sensitivity  Analysis 

The  model  can  perform  four  types  of  sensitivity  analysis.  They  are  swept,  extremes 
only,  wholesale  and  pareto.  In  swept,  the  user  selects  a  range  (for  example,  MTBF  of  200 
to  600  hours)  and  the  program  sweeps  through  the  range  one  LRU  or  SRU  at  a  time.  When 
using  extremes  only,  the  sensitivity  analysis  is  done  only  on  the  upper  an  lower  extremes 
of  the  range  chosen.  In  wholesale  changes  analysis,  all  changes  for  a  given  factor  are  made 
at  the  same  time.  This  is  usually  used  if  the  total  system  cost  is  of  interest  vice  repair 
policy.  In  Pareto,  only  the  highest  cost  or  the  lowest  MTBF  items  are  analyzed  instead  of 
analyzing  all  LRUs  or  SRUs. 

4.  Model  Outputs 

There  are  eleven  types  of  output  presented  by  the  model.  ‘They  contain  data  input, 
intermediate  results,  supplementary  information,  the  optimal  solution,  and  sensitivity 
analysis.”  (ASC/ALTD,  1995)  All  input  record  are  printed  in  the  output.  The  general 
information  output  report  contains  weapon  system  data,  maintenance  system  data,  supply 
system  data,  output  options,  and  wholesale  factors.  Support  Equipment  and  pareto  change 
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factors  are  reported  together.  Repair  Level  Decision  Details  contain  LRU,  LRU  failure 
mode,  and  SRU  data.  Support  Equipment  to  LRU/SRU  Relationships  is  also  an  output 
report.  The  user  of  the  model  can  designate  which  output  options  he  wants  to  receive. 
However,  “the  reports  that  are  not  optional  are  the  Repair  Level  Decisions,  Summary 
Statistics,  Summary  Sensitivity  Analysis  Results,  and  Detailed  Sensitivity  Analysis 
Results.”  (ASC/ALTD,  1995) 

C.  U.S.  NAVY:  LEVEL  OF  REPAIR  ANALYSIS  (LORA) 

1.  Background 

LORA  is  used  to  ensure  the  optimum  economic  use  of  resources.  Its  purpose  is  to 
determine  the  least-cost  feasible  repair  or  discard  decision  with  regard  to  corrective 
maintenance  and  to  influence  the  design  of  the  equipment  toward  that  repair  level  decision. 
In  NAVAIR  this  analysis  can  be  economic,  noneconomic  or  preempting  factors  such  as 
safety  or  security. 

2.  Model  Overview 

-  Model  applies  only  to  corrective  maintenance.  “Preventive  maintenance 
requirement  are  developed  through  the  Reliability-Centered  Maintenance  (RCM) 
process.”  (NAVSEA,  1990) 

-  Model  purpose  is  to  be  done  early  in  the  development  process  “so  that  design  can 
be  influenced  to  allow  for  repairs  to  be  performed  at  the  lowest  possible 
maintenance  level.”  (NAVSEA,  1990) 

-  Model  considers  three  levels  of  maintenance.  They  are  organizational  (O), 
intermediate  (I),  and  depot  (D). 

-  LORA  starts  at  the  system  level  and  then  is  conducted  on  the  item  level. 

-  Final  phase  analysis  is  conducted  to  determine  the  actual  level  of  repair. 
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3.  Final  Phase  Analysis 

This  is  the  last  step  in  determining  the  optimum  repair  level.  This  phase  consists 
five  areas.  They  are  item  level  screen,  O-level  evaluation,  I-level  evaluation,  D-level 
evaluation,  cost  analysis,  and  analysis  of  LORA  results. 

In  item  level  screening,  each  item  in  the  system  is  screened.  ‘The  screening  process 
evaluates  the  item  by  assessing  whether:  (1)  the  item  is  a  consumable,  (2)  the  item  has  such 
a  low  cost  that  an  analysis  is  not  warranted,  (3)  pre-empting  factors  apply,  and  (4) 
remove/replace  decisions  pre-empt  maintenance  at  certain  levels.”  (NAVSEA,  1990)  This 
process  ensures  that  only  the  items  that  warrant  will  receive  a  full  evaluation. 

The  O-level,  I-level,  and  D-level  evaluation  are  basically  the  same.  The  NAVSEA 
manual’s  premise  is  “to  drive  repair  authorization  at  the  Reet  level  (O  or  I-level),  provided 
that  all  the  resources  needed  to  perform  the  repair  are  available  (existing  and  in-place)  at  that 
level,  to  maximize  the  achievement  of  readiness  objectives  and  to  minimize  the  supply 
support  pipeline.  If  the  Reet  does  not  have  the  resources,  cost  analysis  is  performed  to 
determine  the  lowest  maintenance  level  that  should  repair  the  item.”  (NAVSEA,  1990) 

The  performance  of  cost  analysis  is  of  significant  importance.  If  the  capability  for 
repair  does  not  exist  at  any  level,  the  cost  analysis  is  performed  to  determine  the  least  cost 
alternative.  Basically  the  analyst  sums  all  annual  cost  for  the  repair  of  an  item  and  compares 
the  cost  from  each  level  of  maintenanee.  There  exists  a  degree  of  error  based  on  the  level  of 
confidence  associated  with  each  variable.  The  analyst  then  selects  the  least  cost  alternative 
and  determines  the  discard  threshold.  The  discard  threshold  occurs  when  the  unit  repair 
cost  is  greater  than  the  item  cost.  Then  it  is  not  economically  effective  to  repair  the  item. 
After  this  step  then  analysis  of  the  LORA  results  as  a  whole  must  be  performed.  This  must 
be  done  because  although  one  item’s  repair  level  may  have  a  minimal  impact  on  supply 
support,  the  cumulative  result  of  many  items  could  have  a  significant  impact  on  the  supply 
and  support  needed. 
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III.  DMSO  AND  THE  NAVY 


In  this  section  of  the  thesis  we  examine  the  Defense  Modeling  and  Simulation 
Office  (DMSO)  and  its  interaction  with  the  Navy.  We  research  how  DMSO  came  into  being 
and  its  purpose.  We  also  explore  how  the  Navy’s  modeling  and  simulation  office  evolved 
into  its  current  place  in  the  organization  of  the  Navy.  With  computer  modeling  and 
simulation  use  increasing  dramatically  in  logistics,  it  is  important  for  a  navy  logistician  to 
understand  the  organizational  structure,  relationships,  and  some  history  which  may 
continue  to  influence  policy  and  attitudes. 

A.  THE  DEFENSE  MODELING  AND  SIMULATION  OFFICE  (DMSO) 

On  June  21,  1991  the  Defense  Modeling  and  Simulation  Office  (DMSO)  was 
established  by  the  Undersecretary  of  Defense  for  Acquisition.  DMSO’s  purpose  was  to 
“serve  as  the  executive  secretariat  for  the  Executive  Council  on  Modeling  and  Simulation 
(EXCIMS)  and  to  provide  a  full-time  focal  point  for  information  concerning  DoD  modeling 
and  simulation  (M&S)  activities.”  DMSO  is  a  joint  staff  that  reports  to  the  Director, 
Defense  Research  and  Engineering  (DDR&E),  Office  of  the  Undersecretary  of  Defense  for 
Acquisition  and  Technology(USD(A&T)).  (DMSO,  1995) 

DMSO’s  purpose  can  be  fully  understood  by  reading  of  the  foreward  in  the  DoD 
M&S  Master  Plan.  The  foreward  is 


The  DoD  Modeling  and  Simulation  Master  Plan  is  authorized  by  DoD 
Directive  5000.59,  "DoD  Modeling  and  Simulation  (M&S)  Management," 
January  4,  1994.  The  DoD  M&S  policies,  organizational  responsibilities, 
and  management  procedures  are  outlined  in  DoD  Directive  5000.59.  This 
Plan  is  the  Department  of  Defense's  first  step  in  directing,  organizing,  and 
concentrating  its  M&S  capabilities  and  efforts  on  resolving  commonly 
shared  problems.  The  immense  breadth  and  scope  of  DoD  M&S  uses, 
combined  with  the  relative  immaturity  of  many  segments  of  the  larger  DoD 
M&S  community  and  its  technology,  ensure  this  first  iteration  is 
incomplete.  Over  time,  with  the  active  participation  and  support  of  die  DoD 
M&S  community,  this  plan  will  mature  to  address  the  full  range  of  issues 
confronting  DoD  M&S.  Many  policy  and  technical  issues  may  not  be 
identified  or  resolved;  however,  this  plan,  with  the  management  framework 
and  policies  established  in  DoD  Directive  5000.59,  provides  a  means  to 
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achieve  common  technical  and  policy  consensus.  This  plan  is  intended  to  be 
dynamic  and  flexible,  a  living  document  that  will  evolve  as  technology 
matures  and  consensus  develops  on  policy  and  programmatic  issues. 
(DMSO,  1995) 

DoD  management  of  modeling  and  simulation  is  governed  by  DoD  directive 
5000.59.  This  directive  details  the  responsibilities  of  DMSO  and  EXCIMS  and  describes 
how  DoD  will  manage  modeling  and  simulation.  It  is  interesting  to  note  that  the  directive 
mandates,  among  many  other  things,  that  a  DoD  M&S  Master  Plan  be  developed  and  a 
coordinated  DoD  M&S  investment  plan  be  developed.  The  current  version  of  the  DoD 
M&S  Master  Plan  is  available  and  several  functional  area  plans  such  as  acquisition  and 
DoD  investment  are  still  being  developed  two  years  after  this  directive  was  issued. 
Additionally,  only  master  plans  for  the  Army  and  the  Marine  Corps  are  present.  In  essence 
we  are  trying  to  manage  modeling  and  simulation  in  DoD  without  having  a  complete  plan 
from  which  to  work.  DMSO  basically  promulgates  guidance  and  attempts  to  promote 
cooperation  among  all  DoD  components  in  order  to  increase  efficiency  in  the  use  of 
modeling  and  simulation. 

In  order  to  keep  all  services  involved  DMSO’s  staff  is  a  joint  staff.  It  is  comprised 
of  officers  from  the  United  States  Air  Force  (USAF),  the  United  States  Army  (USA),  the 
United  States  Navy  (USN),  and  the  United  States  Marine  Corps  (USMC). 

In  1991,  DMSO  started  out  with  about  $40  million.  In  1992  the  budget  increased 
to  $75  million.  But,  this  year  the  pentagon  cut  the  budget  for  DMSO  to  about  $52  million. 
(Holzer,  1996)  This  is  nearly  full  circle  budgeting  for  this  office. 

In  its  first  year  of  existence  DMSO  began  funding  computer  modeling  and 
simulation.  DMSO  sent  letters  out  to  the  individual  services  requesting  proposals  for 
consideration.  DMSO  funded  16  out  of  230  proposals  and  funded  zero  at  100%. 
Additionally,  the  submitters  of  proposals  were  not  given  any  feedback  on  the  reasons  of 
rejection.  (McMasters,  1992)  The  lack  of  a  strong,  centralized,  modeling  and  simulations 
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management  structure  throughout  DoD  and  a  constant  budget  crunch  means  an  uncertain 
future  also. 

B.  NAVY  INTERACTION  WITH  DMSO 

The  Navy  started  out  with  an  organization  called  Team  Mike.  Team  Mike  screened 
Navy  proposals  and  forwarded  them  to  DMSO  for  consideration.  Team  Mike  started  when 
the  Director  of  ASW  and  Ocean  Surveillance  Programs  was  the  Director  of  Naval  Warfare. 
There  were  several  teams  representing  functional  areas  in  the  Navy.  These  teams  included 
Alpha-antisubmarine  warfare,  Charlie-C3,  and  Mike-modeling.  Team  Mike’s  initial 
concern  was  finding  support  for  wargaming,  enhancing  and  setting  up  Reet  Project  Team 
for  ENWGS  at  the  War  College  and  TACTRAGRU  tool  for  Battle  Group  Commander  and 
staff  training.  (Phillips,  1996) 

When  the  Director  of  ASW  and  Ocean  Surveillance  Programs  became  the  Director 
of  Naval  Warfare  and  later  the  Deputy  Chief  of  Naval  Operations  (DCNO)  for  Naval 
Warfare,  the  Director  of  Tactical  Readiness  Division  reorganized  under  DCNO,  Naval 
Warfare.  The  Heet  Readiness  Section  worked  for  Director  of  Tactical  Readiness  Division. 
The  Reet  Readiness  Section  was  involved  in  studies  at  the  DoD  level.  (Phillips,  1996) 
DMSO  then  came  into  being  with  $70  million  budget  for  the  enhancement  of  modeling  and 
simulation  in  DoD  and  a  plan  for  pilot  and  demonstration  projects.  Team  Mike  became  the 
vehicle  for  the  Reet  Readiness  Section  to  promulgate  opportunities  to  the  Navy  and  screen 
navy  requests  for  submission  to  DMSO. 

The  Reet  Readiness  Section  transitioned  to  the  Navy  Modeling  and  Simulation 
Section.  As  development  of  SECNAV  Instruction  5200.38  began  the  question  of  “who 
owns  Navy  M&S”  was  addressed  at  the  three  and  four  star  level.  It  was  decided  that 
Support  to  Operations  should  own  it.  (Phillips,  1996)  The  initial  transition  from  DCNO, 
Resources,  Warfare  Requirements  and  Assessments  to  Support  to  Operations  was  delayed 
temporarily  until  the  SECNAV  instruction  was  signed.  Additionally,  the  head  of  the 
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Assessment  and  Affordability  Branch  had  departed  in  the  spring  and  the  billet  was  left 
vacant.  Support  to  Operations  decided  to  proceed  with  the  transition  anyway  and  the  Navy 
Modeling  and  Simulation  office  was  placed  into  Strategic  Planning  Office.  The  head  was 
dual  hatted  as  Assistant  for  Strategic  Planning  and  Director,  Navy  Modeling  and  Simulation 
Management  Office.  The  office’s  focus  was  mostly  on  strategic  planning  so  in  mid¬ 
summer,  “CAPT  Jay  Kistler  was  detached  from  SPAWAR  and  reported  in  as  Director, 
Navy  Modeling  and  Simulation  Management  Office.  We  were  then  extracted  from  the 
Strategic  Planning  Office  nest  and  put  on  our  own  as  the  Navy  Modeling  and  Simulation 
Office.”  (Phillips,  1996) 

In  1994  SECNAV  Instruction  52(X).38  was  issued  to  give  instruction  on  the 
management  of  modeling  and  simulation  within  the  Department  of  the  Navy.  Team  Mike 
was  not  included  in  the  formal  management  of  modeling  and  simulation  within  the 
Department  of  the  Navy  structure  because  it  was  determined  that  too  many  of  the  members 
were  traveling  too  much  in  order  to  represent  various  outlying  organizations  such  as 
NRAD,  Port  Hueneme,  etc.  Functional  area  managers  were  established  and  the  use  of 
appropriate  representatives  replaced  Team  Mike. 

Currently,  the  Director  of  Navy  Modeling  and  Simulation  is  a  Navy  captain  and  the 
deputy  is  a  USMC  colonel.  These  positions  rotate.  The  office  establishes  policy  for  Navy 
modeling  and  simulation  and  monitors  the  enactment  of  standards  throughout  the  Navy.  Its 
budget  is  for  these  purposes  only.  Funding  and  management  for  modeling  and  simulation 
comes  from  functional  area  managers.  For  example,  DCNO  for  Training  funds  and 
manages  training.  However,  the  Marines  have  a  quarterly  modeling  and  simulation 
working  group  that  represents  a  wide  range  of  organizations  across  the  Marine  Corps. 
“Fleet  representatives  have  indicated  the  need  for  working  groups.”  (Phillips,  1996) 

The  Navy  Modeling  and  Simulation  Office  attempts  to  keep  abreast  of  all  the 
activity  between  DMSO  and  the  Navy.  However,  this  is  difficult  due  to  the  formal 
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structure  that  is  in  place.  When  the  Director  for  Force  Structure,  Resources  and  Assessment 
set  up  a  project  office,  the  Joint  Analytic  Model  Improvement  Project,  their  point  of  contact 
is  the  Assistant  DCNO  for  Resources,  Warfare  Requirements  and  Assessments.  “Assistant 
DCNO  for  Resources,  Warfare  Requirements  and  Assessments  office  kept  us  informed  of 
their  actions.”  (Phillips,  1996)  Another  example  is  the  Joint  Simulation  Systems  (JSIMS). 
JSIMS  focuses  on  training  and  their  point  of  contact  is  DCNO  for  Training.  ‘The  member 
of  the  JSIMS  ‘General  Officer  Steering  Group’  was  designated  as  an  assistant  under  the 
DCNO  for  Training.”  (Phillips,  1996)  The  Navy  Modeling  and  Simulation  Office  is  not 
large  enough  to  keep  track  of  or  participate  in  all  Navy  interactions  with  DMSO.  The  formal 
structure  requires  DMSO  communicate  with  the  Navy  via  the  Secretary  of  the  Navy 
(SECNAV)  or  the  Chief  of  Naval  Operations  (CNO).  “DMSO  generally  knows  that  to 
communicate  with  the  Navy,  they  need  to  send  us  at  least  an  info  copy  of  the 
material.. ..’’(Phillips,  1996)  However,  most  information  is  gained  through  informal 
communication  within  the  modeling  and  simulation  community. 

Currently  the  Navy  Modeling  and  Simulation  Office  is  developing  a  Baseline 
Assessment  Memorandum,  an  input  into  the  POM  development  process,  addressing  the 
state  of  Navy  modeling  and  simulation.  “Likely  output  is  that  without  a  strong 
Heet/Lab/industry  panel  and  voice.  Navy  M&S  will  be  a  back  burner  issue  and  will  not 
thrive.”  (Phillips,  1996)  Working  Groups  get  the  ultimate  customer  in  modeling  and 
simulation  purchases,  the  user,  more  involved  and  provides  the  management  of  the  Navy 
with  deckplate  information  on  what  is  actually  happening  throughout  the  fleet. 

C.  SHOULD  THE  NAVY  CHANGE  ITS  MANAGEMENT  OF  M&S? 

To  answer  this  question,  the  Navy  should  conduct  its  own  internal  examination.  As 
to  whether  an  internal  examination  should  be  conducted,  we  believe  the  Navy  should  look 
at  what  is  happening  in  one  of  its  sister  services,  the  Army.  “Critics  of  the  manner  in 
which  the  Army  has  invested  in  modeling  and  simulation  say  the  service  has  lacked  a 
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strategy,  efficient  management,  and  oversight.”  The  new  Chief  of  Staff,  Gen.  Reimer, 
empowered  an  office  in  the  Pentagon  to  focus  the  Army’s  modeling  and  simulation.  This 
office  is  the  Simulation  Strategic  Planning  Office  (SSPO). 

The  Simulation  Strategic  Planning  Office  (SSPO)  is  in  charge  of  two  teams  that  are 
“conducting  a  review  of  modeling  and  simulation  projects,  their  funding  and  strategies, 
with  and  eye  toward  identifying  efficiencies.”  One  of  the  duties  of  the  teams  is  to  define 
“what  ‘models’  and  ‘simulations’  are.”  The  teams  are  also  “collecting  a  baseline  of 
information  about  exactly  what  projects  me  taking  place  where;  and  determining  the 
proponents  for  these  projects.”  (Sherman,  1995) 

The  Army  feels  it  is  not  getting  a  return  on  its  modeling  and  simulation  investment 
and  is  conducting  an  internal  review  and  reorganization  before  it  is  ordered  to  do  so. 
Aldiough  SSPO  is  a  new  office,  it  has  an  opportunity  to  provide  a  tremendous  impact  to  the 
future  of  modeling  and  simulation  in  the  Army.  ‘The  new  office  is  to  develop  and  establish 
M&S  standards,  assess  M&S  management  across  the  service,  and  provide  centralized 
strategic  management  with  a  decentralized  execution  of  the  service  M&S  master  plan.” 
(Sherman,  1995) 

We  believe  the  answer  to  the  question  of  change  is  possibly.  The  answer  to  the 
question  of  internal  examination  and  assessment  is  definitely  yes.  The  Navy  should  follow 
the  Army’s  lead  and  take  a  detailed  look  into  where  modeling  and  simulation  dollars  are 
being  spent. 
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IV.  KEY  NAVY  SIMULATIONS  ISSUES 


A.  OVERVIEW 

There  are  two  problems  with  the  use  of  computer  models  and  simulations.  The  first 
is,  how  to  properly  use  models  and  simulations  in  the  many  applicable  areas  to  reduce  cost, 
increase  quality,  and  reduce  time  and  risk  in  fielding  new  weapon  systems.  Second  is  how 
to  buy  models  more  efficiently  and  effectively  by  using  modular  design  and  reusing 
software.  (Kistler,  1996)  The  proper  solutions  to  these  problems  will  dramatically  increase 
the  effective  use  of  computer  models  and  simulations  within  the  Department  of  the  Navy 
and  the  Depeirtment  of  Defense. 

Computer  models  and  simulations  do  not  determine  missions.  The  mission  comes 
first,  then  models  and  simulations.  Matching  computer  models  and  simulations  with 
missions  is  an  important  potential  asset  for  decision  makers.  Well-designed  computer 
models  and  simulations  can  help  decision  makers  understand  risks  and  uncertainties  and 
thus  have  a  more  complete  understanding  of  the  problem  they  are  facing.  Determining  the 
payoff  of  this  use  of  modeling  and  simulation  is  next  to  impossible.  This  is  because  the 
determination  of  a  utility  function  for  the  use  of  modeling  and  simulation  is  almost 
impossible. 

B.  USE  OF  COMPUTER  AIDED  DESIGN  (CAD) 

Probably  the  biggest  ticket  item  in  computer  models  and  simulations  right  now  is 
CAD,  because  CAD  has  the  ability  to  influence  every  major  acquisition  DoD  makes  from 
now  on.  It  is  not  without  some  problems  however.  In  this  section  we  will  address  the  use 
of  CAD  in  the  new  attack  submarine  and  the  surface  combatant  of  the  twenty-first  century 
(SC-21). 

1.  The  New  Attack  Submarine 

The  attack  submarine  program  used  intergraf  CAD2.  Electric  Boat  Corporation 
detailed  Catia  to  develop  a  CAD  like  the  one  used  for  the  Boeing  777.  The  problem  from 
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the  beginning  was  inoperability  between  various  CAD  systems  and  various  shipyards  with 
different  CAD  systems  and  non-transferable  files.  (Henry,  1996)  Also,  CAD  is  a  huge 
initial  investment  for  a  program.  Because  of  the  CAD,  there  are  more  questions,  so  even 
more  time  is  spent  on  feasibility  studies.  For  example,  there  were  about  80  feasibility 
studies  for  the  Seawolf  submarine.  With  the  new  attack  submarine  there  have  been  over 
100  in-house  feasibility  studies  and  dozens  more  done  by  agencies  outside  NAVSEA 
already. 

Prior  to  Electric  Boat  getting  the  contract  the  Navy  was  using  the  Intergraf  CAD 
system  in  the  new  attack  submarine.  Intergraf  is  a  full  blown  geometric  associative  model 
that  is  designed  to  be  run  from  a  database  using  a  network  server.  The  Navy  bought  this  to 
yield  a  product  model.  (Burkeen,  1996)  Each  ship  must  have  its  own  product  model  (3-D 
physical  model).  Intergraif  has  4  core  products  that  are  layered  on  top  of  one  another.  They 
are  an  engineering  model  system  (EMS),  an  vehicle  design  system  (VDS),  a  structural 
model  (IS)  and  a  systems  model  (IR).  The  systems  model  is  piping,  electrical,  etc.  The 
result  is  a  non-integrated,  complex  system  of  software. 

There  are  two  ways  to  design  a  software  system.  The  first  is  top-down.  This 
involves  big  picture  software  design.  The  second  approach  is  bottom-up.  This  approach 
involves  designing  the  little  pieces  which  are  uncoordinated  and  then  integrating  the  entire 
system.  Intergraf  is  a  bottom-up  approach.  The  advantage  is  practically  all  the  software  is 
commercial -off-the-shelf.  The  disadvantage  is  that  the  result  was  software  that  was  bug- 
ridden  and  difficult  to  use.  (Burkeen,  1996)  Corruption  on  a  model  from  a  CAD  and 
associative  CAD  system  will  propagate.  This  is  because  associative  models  are  like  graphic 
programs.  An  example  would  be  machine  parts.  Different  pieces  of  geometry  have 
dependency  or  parents  on  which  to  build.  Then  functions  similar  to  macros  are  run  to  yield 
the  product. 
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The  next  version  of  CAD  comes  out  and  changes  some  commands  and  the  result  is 
implosion  of  the  model.  (Burkeen,  1996)  In  the  early  design  phase  this  happened  and  the 
result  was  a  fiasco. 

The  use  of  CAD  in  detail  became  infeasible  due  to  corruption.  The  corruption 
source  was  a  combination  of  several  factors.  These  include  the  modeler  and  the  complexity 
of  the  system,  lack  of  expertise,  and  the  new  version  of  the  CAD.  The  utility  of  the  CAD 
was  questioned  due  to  the  short  time  frame  of  the  benefit  because  the  files  were  a  non¬ 
retrieval  format  and  therefore  could  not  be  reused.  The  end  result  was  during  early  stage 
design  the  CAD  became  mearly  an  information  system. 

One  of  the  main  preventers  of  progress  in  all  computer  aided  engineering  (CAE) 
being  used  effectively  in  design  is  no  confidential  network  within  the  DoD  agencies  in 
Crystal  City  and  Washington,  D.C.  People  are  performing  the  tasks  manually,  literally 
drawing  on  pieces  of  paper.  CAD  is  more  important  as  a  communication  device.  DoD 
needs  a  functioning  network  and  a  product  data  manager.  Additionally  this  network  needs 
to  be  tied  into  the  shipyards.  This  will  be  a  very  expensive  investment.  But,  the  current 
piecemeal  fashion  of  operation  leads  to  enormous  waste.  The  waste  is  due  to  the  system  not 
being  networked.  The  administrative  cost  and  the  cost  of  software  to  run  stand-alone  at 
NAVSEA  is  huge.  The  reason  is  the  entire  database  must  be  duplicated  at  tremendous  cost 
of  time  and  money  and  risk  corruption  and  then  carried  space-to-space.  Currently  the  CAD 
is  at  Newport  News  and  there  is  no  way  for  NAVSEA  to  access  it.  The  system  needs  to 
have  everyone  on  a  real  network  database  and  everyone  plugged  into  it.  There  should  not 
be  isolated  access  areas  like  there  are  currently.  (Burkeen,  1996) 

Another  major  area  of  concern  is  software  development  and  management.  For 
example,  the  technical  point  of  contact  cannot  monitor  actions  because  he  cannot  test  or 
understand  the  source  code.  The  reason  is  he  gets  a  budget  of  $375,000  for  software 
development.  But,  he  cannot  use  one  cent  to  buy  hardware  or  software  he  needs  because  it 
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is  forbidden  by  law.  The  current  laws  prevent  him  from  using  this  money  for  the  purchase 
of  personal  computers  or  operating  systems  because  these  items  do  not  fall  into  the  imder 
development  category.  “Engineers  are  buying  software  out  of  their  own  pocket  to  make  life 
easier.”  Laws  and  regulations  governing  expenditures  of  money  do  not  match  the  new 
technological  requirements  and  the  procurement  of  software  and  hardware  is  not  on  pace 
with  the  technological  development.  Sanctions  are  preventing  the  procurement  of 
inexpensive  alternatives.  (Burkeen,  1996) 

The  management  of  the  Federal  acquisition  process  is  highly  regulated  and 

IT  procurements  are  subject  to  the  following  laws  and  regulations: 

-Brooks  Act  (P.L.  89-306) 

-Warner  Amendment  (P.L.  99-500) 

-Paperwork  reduction  Act  (P.L.  96-51 1) 

-Paperwork  reduction  Reauthorization  Act 
of  1986  (P.L.  99-500) 

-Competition  in  Contracting  Act  (P.L.  98-369) 

-Computer  Security  Act  of  1987  (P.L.  100-235) 

-Privacy  Act  of  1^4  (P.L.  93-579) 

-Federal  Acquisition  Regulation  (FAR) 

-Federal  Information  Resources  Management 
Regulation  (FIRMR) 

-Federal  Property  Management  Regulation  (FPMR) 

-OMB  Circular  A- 130,  Management  of  Federal 

Information  Resources 

-OMB  Circular  A-76,  Policies  for  Acquiring 

Commercial  or  Industrial  Products  and  Services 

Needed  by  the  Government 

-OMB  Circular  A-109,  Major  Systems  Acquisitions 

-Plus  any  agency  specific  guidance  regarding 

acquisition  and  operation  of  IT  resources.  (Willis,  1994) 

2.  The  Surface  Combatant  of  the  Twenty-first  Century  (SC-21) 

The  SC-21  is  also  using  the  CAD  in  its  program.  In  use  is  a  Product  Model 
Enhancement  (PME).  This  graphic  CAD  system  was  developed  by  Intergraf  in  April  1990 
and  used  heavily  in  the  LPD-17  program.  Conceptual  improvements  were  made  in  the 
system  for  use  in  the  SC-21.  The  CAD  is  being  used  to  place  items  on  the  ship  in  the 
design  phase. 
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These  items  are  graphically  designed  and  placed  into  a  data  base.  During  the  ship  design 
phase  about  20%  of  the  items  are  modeled  in  the  CAD  file  and  about  80%  are  in 
specifications  files  or  other  non-graphic  files.  (Zebrowski,  1996) 

The  PME  control  of  the  product  database  has  been  under  development  for  about 
two  years.  This  data  base  concept  allows  the  entire  ship  and  all  the  parts  of  the  ship  to  be 
entered  into  the  data  base  without  graphics.  As  the  design  progresses  the  design  can  be 
updated.  By  mid-March  this  concept  will  be  in  full  use  for  the  SC-21. 

The  CAD  system  that  will  be  used  involves  three  different  software  items.  They  are 
PME,  Docmgr2,  and  metaphase.  The  system  currently  uses  Orcle  which  is  a  relational 
software.  However,  the  SC-21  program  will  be  switching  to  Informix  because  they 
currently  own  the  license  to  Informix  along  with  CAD2.  Docmgr2  is  a  commercial 
document  management  system  produced  by  Intergraf.  It  is  based  on  metaphase  which  is  an 
object  oriented  management  system.  Now  Orcle  is  a  very  robust  system  with  a  distributed 
data  base  that  is  designed  to  be  networked.  But,  there  is  a  logistics  problem  with  security. 
The  SC-21  program  will  probably  get  around  the  lack  of  secure  network  problem  that  is 
also  present  in  the  new  attack  submarine  program.  The  SC-21  program  plan  is  to 
piggyback  on  the  modeling  and  simulation  site  in  NAVSEA  since  this  links  to  secure  sites 
in  other  model  and  simulation  centers. 

Currently  Intergraf  is  comparing  Informix  and  Orcle.  This  is  to  ensure  that  essential 
capabilities  will  not  be  lost  when  the  program  switches  software.  If  the  findings  of  the 
study  indicate  that  some  capabilities  that  are  considered  essential  will  be  lost  then  the  SC-21 
program  will  stay  with  Orcle.  (Zebrowski,  1996) 

Potential  problems  with  the  use  of  CAD  in  the  design  and  building  of  surface  ships 
became  evident  in  the  DDG-51  program.  There  were  two  different  shipyards  with  two 
different  CAD  systems. 
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With  the  use  of  CAD,  there  is  a  tendency  to  do  some  things  on  the  ship  first  and  then  go 
back  to  the  CAD  and  try  to  fix  it.  (Zebrowski,  1996)  In  order  for  CAD  to  work  properly 
the  discipline  to  use  the  model  must  be  maintained. 

Currently,  the  CAD  can  only  handle  one  ship  vice  a  class  of  ships.  In  order  to  use 
the  CAD  for  a  second  ship  of  the  class,  the  data  base  must  be  created  from  the  beginning. 
Phase  2  of  the  product  model  enhancer  is  being  designed  to  handle  classes  of  ships.  It  is 
also  being  designed  to  share  the  data  amongst  the  ships  of  the  class.  This  means  to  design 
the  second  ship  of  the  class  the  data  base  will  not  have  to  be  created  from  scratch. 

Does  CAD  yield  a  design  faster?  The  answer  to  this  question  is  both  yes  and  no. 
For  example,  by  hand  maybe  you  could  do  5  studies  per  week  and  now  you  can  do  10 
studies  per  week.  This  improvement  will  hopefully  allow  you  to  get  a  better  design  out  of 
the  process.  If  you  reduced  the  number  of  people  because  of  computers,  then  your  output 
will  be  the  same  as  before  computers.  CAD  still  takes  time  but  people  ask  for  more  things 
more  often.  There  is  the  perception  that  if  it  is  “done  by  computer,  it’s  instantaneous.” 
(Zebrowski,  1996) 

C.  JSF  (JOINT  STRIKE  FIGHTER) 

1.  Background 

Joint  Strike  Fighter  (JSF),  previously  known  as  Joint  Advanced  Strike  Technology 
Program  (JAST),  is  a  joint  program  for  the  development  of  a  new  aircraft.  JSFs  vision  is 
“A  Joint  Services  Team  creating  the  building  blocks  for  affordable,  successful  development 
of  the  next  generation  strike  weapon  systems.”  The  service  needs  are  as  follows.  For  the 
U.S.  Navy,  a  “first  day  of  war,  survivable  strike  fighter  aircraft  to  complement  the  F/A- 
18E/F.”  The  U.S.  Air  Force  needs  a  “multi-role  aircraft  (primary  A/G)  to  replace  the  F- 
16.”  Finally,  the  U.S.  Marine  Corps  needs  a  “ASTOVL  aircraft  to  replace  the  AV-8B  and 
F/A-18.”  The  program  is  concentrating  on  developing  a  family  of  three  aircraft. 
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The  goal  is  to  use  a  common  production  line  to  build  the  most  affordable  aircraft  and  to  add 
service  unique  items  to  the  aircraft.  An  example  of  a  service  unique  item  is  the  Navy’s 
aircraft  carrier  shipboard  tailhook.  (Hamman,  1995) 

2.  Organization 

JSF  is  a  highly  successful  joint  acquisition  program.  Its  success  is  directly 
attributable  to  its  organization.  The  director  of  the  program  is  U.S.  Air  Force  and  the 
deputy  is  U.S.  Navy.  These  positions  rotate  according  to  normal  personnel  rotation  plan. 
This  arrangement  ensures  both  principal  parties  best  interest  in  the  program  is  maintained 
and  ensures  teamwork.  “The  organization  functions  as  integrated  product  teams.” 
(Hamman,  1995) 

3.  Other  JSF  Issues 

The  JSF  program  is  using  an  extensive  modeling  and  simulation  process  that 
includes  virtual  environment,  prior  to  flight  test.  Although  this  modeling  and  simulation  is 
on  a  much  smaller  scale  than  the  entire  Department  of  the  Navy  or  the  Department  of 
Defense  its  success  is  due  to  its  organization  and  management.  One  office  manages  and 
acts  as  a  clearinghouse  for  all  simulations  with  the  program.  The  money  flow  is  directly 
traceable  from  the  director  down  and  the  exaet  amount  of  dollars  being  spent  on  computer 
modeling  and  simulations  is  known. 

In  the  area  of  simulations,  there  does  not  appear  to  be  a  strong  simulations 
applications  program  in  place.  There  is  an  area  in  the  “Modeling  Simulation  &  Analysis 
Process”  for  JSF  that  is  called  “constructive  simulation”.  However,  when  examining  this 
area  in  detail  it  looks  as  if  this  is  the  use  of  different  models  to  evaluate  campaign,  mission, 
etc.  and  not  a  graphical  simulation  program.  There  are  several  areas  in  which  a  graphical 
simulation  would  be  beneficial  to  the  decision  makers.  One  of  these  would  be  a  simulation 
of  the  “common  production  line.”  (Hamman  1995) 
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We  did  note,  with  some  interest  that  while  JSF  is  a  joint  program,  the  analysis  of 
the  Services  logistic  data  is  being  kept  separate.  “So  analysis  on  USAF  comparative  data 
would  use  NRLA  and  USN  data  would  use  LORA.  We  have  not  reached  the  point  where 
production  or  production-like  designs  are  being  looked  at  in  detail  by  government 
analysts.”  (Hamman,  1996)  NAVAIR  has  taken  the  lead  in  developing  the  Joint  Aviation 
Model  (JAM)  for  use  in  the  JSF  program.  JAM  will  be  discussed  in  detail  in  Chapter  V  of 
this  thesis. 

D.  CONTINUOUS  ACQUISITION  AND  LIFECYCLE  SUPPORT  (CALS) 

“  Continuous  Acquisition  and  Lifecycle  Support  (CALS,  also  known  as  Commerce 
At  Light  Speed)  is  a  strategy  to  accelerate  the  transition  from  paper-intensive  non-integrated 
product  development  design  and  manufacturing,  and  support  processes  to  a  highly 
automated,  integrated  mode  of  operation  by  developing  (1)  standards  for  data  storage  and 
exchange;  and  (2)  automated  systems  to  store,  manage,  and  distribute  this  information  to 
many  and  varied  users  across  an  enterprise.”  (CALS,  1996)  CALS  was  originally 
developed  in  1984  and  was  known  as  Computer-Aided  Logistic  Support.  The  Deputy 
Secretary  of  Defense  issued  two  memorandums  “to  establish  plans  to  acquire,  process,  and 
use  technical  information  in  digital  form.”  (CALS,  1996)  In  1987,  the  name  was  changed 
to  Computer-Aided  Acquisition  and  Logistic  Support.  “This  brought  in  functions  and 
disciplines  associated  with  contracting,  work  breakdown  structures,  design  specifications, 
drawing  preparation  and  release,  testability,  produce-ability,  reliability  and  maintainability.” 
(CALS,  1996)  Later,  CALS  name  was  change  to  its  current  form  and  more  government 
agencies  became  involved.  CALS  is  now  starting  to  attract  European  and  Pacific  Rim 
countries. 

Why  did  CALS  start?  The  answer  to  this  question  is  money.  DoD  managed  many 
of  its  weapons  systems  and  acquisitions  manually  and  on  paper.  “DoD  spends  more  than 
$10  billion  annually  to  store,  maintain,  and  revise  the  technical  data  needed  to  support 
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weapon  systems.”  For  example,  “the  technical  manuals  needed  to  perform  maintenance  and 
repair  on  a  Navy  destroyer  weigh  23.5  tons.  Overall,  the  Navy  maintains  more  than  237 
million  drawings  and  more  than  15  million  technical  manuals,  at  an  annual  cost  of  over  $4 
billion.”  The  other  branches  over  service  spend  similar  amounts  of  money  on  these  same 
types  of  items.  (CALS,  1996) 

“The  objectives  of  CALS  are  to  improve  timeliness,  reduce  cost  and  improve  the 

quality  of  products  and  their  supporting  technical  data.”  The  accomplishment  of  these 

objectives  is  essential  for  the  military  and  the  government  in  this  era  of  declining  budgets. 

The  immediate  goal  of  CALS  is  to  provide  basic  capabilities  for  the  digital 
transfer  of  engineering  drawings,  technical  and  training  manuals  and  logistic 
support  products.  The  longer  term  goal  is  the  development  of  integrated 
databases  that  represent  all  current  technical  data  about  a  product  through 
each  stage  of  its  life  cycle.  It  is  through  this  long  term  goal  of  shared 
databases  that  integrated  product  development  (concurrent  engineering)  and 
other  parallel  acquisition  processes  can  take  place.  (CALS,  1996) 

CALS  will  achieve  these  objectives  by  using  standards.  “CALS  incorporates  three 

types  of  standards.”  They  are  functional,  technical  interchange,  and  data  standards. 

Functional  standards  refer  to  “  data  creation  and  the  content  and  format  of  data  products.” 

Technical  interchange  standards  are  standards  “which  control  the  medium  and  process  of 

exchanging  data  between  sending  and  receiving  systems.”  Data  standards  “govern 

information  sharing  and  data  exchange  in  an  open  system  environment.  CALS  philosophy 

is  that  to  function  competitively,  management  must  realize  that  national  and  international 

standards  are  the  conduits  for  carrying  U.S.  Products,  services,  and  technologies  into  the 

global  marketplace.  (CALS,  1996) 

In  order  for  CALS  to  accomplish  the  aforementioned  goals  and  objectives  STEP 
must  be  developed  and  implemented.  “STEP  is  being  designed  to  give  a  complete, 
unambiguous,  computer  interpretable  representation  of  a  product  throughout  its  lifecycle.” 
This  is  a  progression  from  sharing  data  to  multiple  user  interface.  In  this  system  many 
users,  organizations,  producers  and  consumers  will  be  able  to  access  life  cycle  data  on  a 
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product.  “Data  access  delivery  and  distribution  will  be  through  Contractor  Integrated 
Technical  Information  Services  (CITIS).  CITIS  is  the  vehicle  to  provide  consumers  with 
access  to  information  associated  with  life  cycle  product  development.”  This  information 
system  will  control  access  to  data  and  ensure  that  users  can  access  only  what  they  are 
authorized  to  access.  (CALS,  1996) 

As  previously  stated,  a  long  term  goal  of  CALS  is  integrated  product  development 

or  concurrent  engineering.  STEP  is  the  essential  element  to  achieving  this  goal. 

Concurrent  Engineering  is  the  systematic  approach  to  creating  a  product 
considering  all  lifecycle  elements  and  in  doing  so,  simultaneously  defining 
the  product,  manufacturing  process,  and  support.  Concurrent  Engineering 
applied  to  manufacturing  is  a  critical  link  in  the  enterprise  and  life  cycle  of 
any  product.  CALS  is  the  integration  of  information  whereas  Concurrent 
Engineering  is  the  integration  of  processes.  This  combination  is  necessary 
to  achieve  the  ultimate  goal  of  Enterprise  Integration.  (CALS,  1996) 

CALS  has  become  a  key  logistics  ingredient  in  several  Navy  programs.  One  of 

these  programs  is  the  Seawolf  attack  submarine  program  .  Newport  News  Shipbuilding  is 

the  lead  design  yard  for  the  Seawolf.  “To  stay  competitive,  CALS  principles  and  concepts 

are  imbedded  in  designing  and  building  major  weapon  systems.  This  fact  has  been  most 

apparent  in  the  design  of  the  Seawolf,  the  first  submarine  totally  designed  using 

computers.”  The  development  and  implementation  of  STEP  will  be  the  last  item  needed  to 

make  CALS  complete.  “The  technology  and  standards  for  exchanging  a  fully  attributed, 

three-dimensional  solid  model  are  not  yet  available-for  that  we  must  have  STEP.”  (Burke, 

1992)  In  the  meantime,  CALS  principles  and  concepts  are  being  used  and  probably  will 

remain  in  place  for  long  into  the  future. 
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V.  JOINT  SIMULATIONS 
A.  JAM  (JOINT  AVIATION  MODEL)  FOR  LORA 

In  this  section  of  the  thesis,  we  take  a  brief  overview  of  JAM.  JAM  was  developed 
because  there  did  not  exist  a  tool  to  provide  a  Joint  NA  VAIR/Air  Force  acquisition  program 
repair/discard  decisions.  “JAM  is  being  produced  to  provide  a  single  (software  application) 
level  of  repair  analysis  model  to  accommodate  the  Navy,  the  Air  Force,  and  Joint  program 
needs.  A  Memorandum  of  Understanding  between  NA VAIR  and  Air  Force  (Jan  93)  agreed 
to  pursue  this  joint  project.  The  Air  Force  provided  $150K  from  the  V-22  program  and 
NAVAIR  provided  $37K  (and  agreed  to  provide  additional  funding  as  required.)” 
(Hamman,  1996)  The  information  contained  in  this  section  was  obtained  from  the  paper 
“The  Genesis  of  JAM  for  LORA”  by  Stephen  H.  Doragh. 

1.  Background 

The  idea  for  a  joint  Level  of  Repair  Analysis  (LORA)  program  initially  began  at  the 
V-22  “Osprey”  program  office  at  Naval  Air  Systems  Command  (NAVAIRSYSCOM)  in 
1993.  “Joint  acquisition  programs  area  those  that  involve  more  than  one  service  (Army, 
Navy,  Marine  Corps,  United  States  Air  Force  (USAF),  and  occasionally.  Coast  Guard,  & 
Federal  Aviation  Administration  (FAA))  in  the  development  and  acquisition  of  a  weapons 
system  by  the  government.  In  the  case  of  the  V-22,  all  three  military  services  were  involved 
when  the  acquisition  program  began. ’’(Doragh,  1995)  Joint  programs  present  a  whole  new 
set  of  problems  for  the  program.  Each  service  has  its  own  LORA  models  for  its  own 
acquisitions.  Each  LORA  model  is  biased  toward  the  maintenance  philosophy  and  policies 
of  the  individual  service.  “For  example,  NAVAIR’ s  model  provides  for  aircraft  to  be 
stationed  on  aircraft  carriers,  the  Army’s  model  has  five  repair  levels,  and  the  USAF’s 
model  is  designed  to  be  run  by  end  item.  However,  in  light  of  the  smaller  defense  budgets 
projected  for  the  future,  it  is  assured  that  ‘joint’  programs  will  become  more  and  more 
common.”  (Doragh,  1995) 
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The  peculiarities  of  each  services’  models  create  a  quandary 
for  the  program  office  of  a  ‘joint’  program.  Do  they  use  one 
service’ s  LORA  model  for  dl  repair  level  studies  and  accept 
that  the  selected  model  will  not  precisely  fit  all  of  the 
services’  maintenance  scenarios?  Or  do  they  allow  each 
service  to  use  their  own  model  for  the  end  items  they  will 
operate,  e.g.,  “Enter  the  Navy’s  aircraft  in  a  navy  model  and 
enter  the  USAF’s  aircraft  in  the  Air  Force’s  model?”  The 
problem  with  the  latter  approach  is  that  any  advantages 
gained  by  having  combined  LORA  runs  and  optimizing  the 
support  equipment  use  for  all  Intermediate  Maintenance 
Activity  (IMA)  sites  and  depots  are  lost.  (Doragh,  1995) 

This  led  the  Osprey  program  office  to  begin  pursuing  a  joint  LORA  model.  “They 

realized:  (1)  that  NAVAIR  and  USAF  have  very  similar  maintenance  philosophies  for 

corrective  repair  of  aircraft  and  its  equipment;  (2)  that  one  LORA  model  could  be  developed 

for  use  by  both  services;  (3)  that  each  service  also  had  its  own,  aging  LORA  model  that 

required  updating;  and  (4)  both  models  used  old  software  techniques  that  did  not  take 

advantage  of  the  capabilities  of  modem  personal  computers. ’’(Doragh,  1995)  The  result  of 

this  pursuit  is  JAM  for  LORA. 

2.  LORA/NRLA  Similarities 

-  “Both  models  calculate  the  total  operating  hours  of  all  operating  end  items  at  all 
operating  sites  to  determine  the  total  number  of  failures  for  the  items  under 
analysis.” 

-  “The  USAF  s  maintenance  planning  policy  has  a  greater  bias  towards  two  level 
maintenance  (Organizational  Level  to  the  Depot)  than  the  Navy’s  policy.  However, 
both  models  require  the  user  to  enter  data  as  if  the  items  under  analysis  were  going 
to  be  repaired  using  a  three  level  maintenance  concept  (Organization  to  Intermediate 
to  Depot).  The  models  then  test  both  the  two  level  concept  and  the  three  level 
concept  to  determine  the  maintenance  plan  with  the  lowest  cost  for  maintenance 
over  the  life  cycle  of  the  system  being  studied.”  (Doragh,  1995) 
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-  “Both  models  determine  the  cost  “impact”  of  a  maintenance  concept  on  existing 
maintenance  sites.  The  models  assume  that  the  sites  already  exist  with  hangars, 
runways,  common  support  equipment,  and  a  standard  manpower  complement. 
They  measure  what  the  costs  of  adding  the  items  under  analysis  to  these  sites  will 
be  in  various  combinations  and  compare  them  to  each  other.” 

-  Both  models  lack  a  on-line  help  feature. 

-  Both  models  were  designed  for  use  in  a  non-Windows  environment. 

-  Both  models  were  designed  and  produced  before  LSAR  Mil-Std’s-1388.2A  or 
1388.2B  were  developed  so  they  cannot  take  full  advantage  of  the  LSAR  database. 

-  Both  models  were  written  in  older  computer  languages  (NRLA-  FORTRAN; 
LORA-  C-I-). 

-  Like  all  software  programs,  both  models  require  updating  or  improvement  but 
neither  had  a  steady  funding  source  for  this  purpose. 

-  “Both  models  assign  the  “costs  of  support  equipment”  to  the  LORA  candidates 

that  use  the  support  equipment  before  the  optimization  is  begun.”  The  way  the 

models  assign  the  costs  vary  slightly.  However,  this  is  a  problem  for  both  models. 

The  fundamental  problem  with  these  methods  of  optimizing 
LORA  data  is,  the  models  are  attempting  to  determine  the 
support  equipment  cost  for  each  item  at  each  site  before  the 
repair  level  has  been  determined.  When  using  these 
methods,  the  model  cannot  always  know  how  many  items 
are  going  to  be  repaired  at  a  site  and  cannot  determine  how 
many  hours  per  month  a  piece  of  support  equipment  is  used. 

So,  the  model  cannot  always  know  how  many  pieces  of 
support  equipment  need  to  be  purchased  for  each  site  or  how 
to  allocate  the  costs  of  the  support  equipment  to  the  items  at 
each  site.  (Doragh,  1995) 

3.  JAM  Algorithm 

In  setting  up  JAM  for  LORA,  the  team  realized  the  flaws  in  LORA  and  NRLA. 
They  realized  that  those  optimization  models  “did  not,  and  could  not,  always  return  the  best 
solution  for  all  items  and  support  equipment.”  (Doragh,  1995)  There  are  basically  two 
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options  for  the  optimization  routine.  “What  we  discovered  was  that  we  had  two  choices:  (1) 

perform  an  analysis  on  every  possible  alternative,  called  an  ‘exhaustive’  search;  or  (2)  use  a 

new  optimization  routine  that  mimic  Charles  Darwin’s  theory  of  evolution  or  ‘natural 

selection’  called  ‘Genetic  algorithms.’”  (Doragh,  1995) 

An  exhaustive  search  was  determined  to  unfeasible.  The  total  number  of  possible 

maintenance  plans  was  found  to  be  equal  to  the  number  of  repair  levels  raised  to  the  power 

of  the  number  of  items  under  consideration.  Each  service  defined  what  they  considered  a 

valid  maintenance  plan.  This  total  number  includes  plans  that  would  be  considered  invalid. 

The  two  constraints  that  any  valid  maintenance  plan  must 
adhere  to  are:  (1)  A  lower  indenture  level  assembly  must  be 
repaired  at  the  same  site  level  or  higher  site  level  as  its  next 
higher  indenture  level  assembly.  When  running  LORA’s  the 
lowest  site  level  is  the  ‘squadron’  or  ‘organizational’  level, 
the  next  highest  site  level  is  the  ‘depot’  (commercial  or 
organic),  and  the  highest  repair  decision  is  ‘discard’.  (2)  All 
lower  indenture  level  assemblies  of  a  discarded  candidate  are 
discarded  with  that  item;  that  is,  no  analysis  is  performed  for 
those  lower  indenture  level  discarded  items.  (Doragh,  1995) 

The  reason  that  the  exhaustive  method  was  abandoned  was  the  computation  time.  For 

example,  “suppose  an  input  file  has  three  levels  (IMA,  depot,  &  discard)  and  15  items,  the 

total  number  of  alternatives  is  14,348,907.”  If  you  eliminated  half  of  the  alternatives  due  to 

violation  of  the  valid  maintenance  plan  constraints,  and  assumed  only  30  seconds  to 

complete  the  computations  for  each  iteration  of  the  model,  “it  would  take  about  60,000 

hours  (or  2491  days  or  6.8  years)  to  finish  all  of  these  runs  and  find  the  optimal  solution.” 

(Doragh,  1995) 

Thus  the  “Genetic  Algorithm”  (GA)  was  selected  as  the  best  alternative  to  pursue. 
The  algorithm  basically  uses  the  rules  of  nature  to  find  the  best  solution.  It  searches  a  “state 
space”  where  all  possible  solutions  are  located.  Then  the  algorithm  combines  “parts  of  the 
most  successful  solutions,  to  create  more  successful  solutions  using  a  process  called 
‘mating’”.  (Doragh,  1995)  The  cost  module  is  separate  in  JAM.  The  GA  creates 
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maintenance  alternatives  to  be  evaluated  by  the  cost  module.  ‘The  cost  of  the  alternative  is 
returned  to  the  genetic  algorithm  and  then  the  genetic  algorithm  determines  the  relative 
quality  of  the  answer.”  (Doragh,  1995)  It  avoids  the  support  equipment  problem 
experienced  by  the  other  models  by  giving  the  repair  level  for  every  item  to  the  cost  module 
by  the  GA.  “JAM  for  LORA  is  ‘given’  and  then  calculates  exactly  which  pieces  of  support 
equipment  are  required  for  every  site  and  how  many  of  each  support  equipment  are 
required  for  each  site,  for  every  iteration  of  the  Cost  Module.”  (Doragh,  1995) 

4.  JAM  Characteristics 

-  It  can  be  used  for  joint  Navy/USAF  programs.  Navy  only  programs,  or  USAF 
only  programs. 

-  It  operates  in  the  Windows  environment. 

-  It  is  user  friendly. 

-  It  has  on-line  help. 

-  It  continuously  updates  its  database  as  the  user  enters  data. 

-  It  is  written  in  a  database  computer  language  (Foxpro). 

-  It  “calculates  the  total  number  of  operating  hours  per  month  at  each  site  for  each 
aircraft  type  (or  end  item).”  (Doragh,  1995)  This  allows  the  user  to  compute  “site 
operating  hours.” 

-  It  can  show  an  “Item  Efficiency  Index”.  “This  is  an  output  report  that  shows  the 
relative  impact  of  changing  inputs  that  affect  an  item’ s  ‘availability’  ”. 

(Doragh,  1995) 

-  It  can  run  separate  “systems”  in  the  same  model  run. 

5.  JAM  Reports 

JAM  for  LORA  has  the  ability  to  generate  the  following  reports: 

-  Item  repair  dispositions 

-  Item  disposition  (detail/summary) 
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-  Life  cycle  cost  (detail/summary/summary  by  site) 

-  Support  equipment 

-  Inventory  (detail/summary) 

-  Optimization  graph/list 

-  Standard  summary 

-  Top  ten  summary 

-  Sensitivity  analysis  (Doragh,  1995) 

6.  Engine  LORA  Model  (ELM) 

Also  under  development  is  ELM.  This  model  is  very  similar  to  JAM  except  it  is 
tailored  for  gas  turbine  engines.  It  will  also  have  the  ability  to  be  used  for  Navy  only, 
USAF  only,  or  joint  USAF/Navy  engine  programs. 

B.  JOINT  MATH  MODELS 

In  this  section,  we  will  discus  briefly  several  joint  math  models  being  developed  at 
the  Joint  Logistics  Systems  Center  (JLSC).  The  purpose  of  these  projects  is  to  look  at 
standardizing  models  used  for  setting  wholesale  and  retail  inventory  levels.  It  is  the 
intention  of  this  section  to  give  a  logistician  some  insight  into  the  tools  currently  being 
developed. 

1.  Statistical  Demand  Forecasting  (SDF) 

This  model’s  purpose  is  to  forecast  the  mean  and  variance  of  the  net  demand  during 
the  procurement  leadtime  and  the  demand  during  the  repair  tum-around-time  for  use  in 
requirements  determination.  “This  model  forecasts  the  means  and  variances  (where 
appropriate)  for  the  following  variables:  demand,  regeneration,  final  recovery  rate, 
unserviceable  returns,  unserviceable  return  rates,  serviceable  return  rates,  nonrecurring 
demand  rates,  administrative  leadtime,  production  leadtime,  procurement  leadtime, 
retrograde  time,  administrative  repair  time,  depot  maintenance  time,  and  depot  repair  cycle 
time.”  When  using  the  model,  different  forecasting  items  are  available  for  different  items. 
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The  model  can  be  applied  to  consumable  and  repairable  items,  program  and  nonprogram 
related  items,  and  family  and  bachelor  items. 

‘The  model  uses  Statistical  Process  Control  (SPC)  techniques  to  identify  when  a 
change  in  the  demand  pattern  is  statistically  significant  and  requires  an  update  (or  change) 
to  the  forecast.”  It  can  also  provide  for  the  identification,  exclusion,  or  modification  prior  to 
use,  of  outlier  observations.  The  model  has  the  ability  to  identify  trends  and  adjust  the 
forecast  accordingly.  “The  SDF  consists  of  two  parts:  a  ‘black  box’  subroutine  accessed  by 
Requirements  Control  System  (RCS)  and  Central  Secondary  Item  Strati-fication  (CSIS); 
and,  a  PC  Exception  Tool,  used  to  review/change/simulate/re-forecast  items.”  (Moore, 
1996) 

2.  Economic  Order  QuantityA^ariable  Safety  Level  (EOQA^SL) 

The  EOQ/VSL  math  model  is  used  for  computing  inventory  levels  for  secondary 
items.  This  model  does  the  mathematical  calculations  and  processes  required  for  this 
computation.  “The  model  acts  as  a  ‘black  box’  accessed,  as  required,  by  DoD  systems, 
including  the  Requirements  Computation  System  (RCS),  Simulation  Recomputation  Tool 
(SRT),  Central  Secondary  Item  Stratification  (CSIS),  and  Computation  and  Research 
Evaluation  System/Supply  Performance  Analyzer  (CARES/SPA).”  In  the  model 
consideration  can  be  given  to  both  family  and  nonfamily  items. 

The  system  basically  provides  output  based  on  whatever  input  it  is  given.  “The 
accessing  system  provides  the  input  and  parameter  data  and  the  model  returns  the  output 
data  to  the  accessing  system.”  The  model  performs  all  necessary  mathematical 
computations  to  determine  when  and  how  much  material  to  buy  and  repair,  “as  required  by 
RCS,  SRT,  CSIS,  and  CARES/SPA.”  The  model  will  compute  order  and  repair  quantities 
and  reorder  and  repair  levels.  It  can  compute  for  consumable,  repairable,  family  and 
nonfamily  items.  “Necessary  preliminary  calculations  (initial  values  and  constraints  and 
special  case  establishment  and  follow-on  calculations  (backorder,  final  quantities. 
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performance  projections,  and  family  prorating)  are  also  performed  by  this  model.”  (Moore, 
1996) 

3.  Computational  And  Research  Evaluation  System/Supply 

Performance  Analyzer  (CARES/SPA) 

CARES/SPA  provides  the  information  necessary  to  set  parameters  used  in  the  RCS 
and  CSIS.  It  is  a  stand  alone  point-in-time  simulation  system.  “  CARES/SPA  provides  and 
experimental  tool  to  evaluate  proposed  inventory  methods  and  models  and  to  determine 
shortage  cost  values.”  The  EOQ/VSL  “black  box  is  the  common  model  used  in  the 
CARES/SPA,  RCS,  CSIS,  and  the  Simulation  Recomputation  Tool  (SRT).” 

The  CARES/SPA  model  may  be  used  on  a  sample  grouping  (e.g.,  “universe  of 
items  with  similar  characteristics)  using  one  of  the  four  different  target  types.  The  types  are 
fill  rate,  dollar  value  safety  level,  average  wait,  and  a  chosen  lambda  value.  When  using  the 
first  three  types,  the  model  searches  for  a  lambda  that  will  achieve  the  specified  target  level. 
“The  fourth  option  evaluates  certain  lambda  values  to  determine  the  impact  on  measures 
such  as  fill  rate,  average  wait,  inventory  investment,  and  cost  and  number  of  first  year 
buys.”  CARES/SPA  has  a  Multi-Link  capability.  The  user  of  the  program  can  select  a 
target  either  by  National  Stock  Number  (NSN)  or  NSN  group.  “For  certain  user-specified 
items,  Multi-Link  provides  a  multi-echelon  computation  to  determine  Ihe  performance  target 
that  the  wholesale  echelon  should  provide.”  It  should  be  noted  that  all  outputs  provided  by 
CARES/SPA  for  non  Multi-Link  items  are  also  provided  for  Multi-Link  items.  (Moore, 
1996) 

4.  Readiness-Based  Sparing  (RBS) 

In  the  world  of  computer  models,  new  models  are  being  developed  constantly  for 
application.  At  JLSC,  another  joint  model  being  developed  is  RBS.  Although  very  few 
details  are  available  on  RBS,  it  serves  as  an  example  on  the  constant  growth  in  the  field  of 
math  models.  JLSC  is  developing  “retail  readiness-based  sparing  (RBS)  models  which  are 
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used  to  determine  secondary  item  requirements  for  retail  (user)  sites  in  a  manner  which 

provide  the  most  readiness  per  dollar  of  inventory  investment. ’’(Moore,  1996) 

C.  JOINT  SIMULATION  SYSTEMS  (JSIMS) 

In  this  section  we  will  look  at  another  Joint  simulation.  While  not  directly  a  logistic 

model  or  simulation,  it  provides  some  insight  into  potential  problems  that  are  faced  when 

conducting  a  Joint  program.  Even  though  the  future  of  simulations  and  models  is  joint, 

they  are  under  constant  scrutiny  and  must  be  managed  carefully. 

“The  General  Accounting  Office  (GAO)  says  the  Defense  Department’s  effort  to 

develop  a  Joint  Simulation  System  is  well  behind  schedule  and  still  lacking  a  consistent 

focus,  which  auditors  say  could  allow  DoD  to  pursue  unnecessary  upgrades  to  the  current 

system  and  let  services  develop  programs  that  may  duplicate  the  capabilities  of  JSIMS.” 

(Dupont,  1995)  The  GAO  is  under  the  opinion  that  “the  JSIMS  program  ‘hcis  not 

progressed  beyond  the  conceptual  stage  since  a  memorandum  of  agreement  was  signed  in 

June  1994.’”  (Dupont,  1995)  It  was  intended  for  JSIMS  to  replace  the  Army’s  current 

Aggregate  Simulation  Protocol  (ALSP),  which  is  currently  managed  by  the  Army’s 

Simulation,  Training  and  Instrumentation  Command.  (Dupont,  1995) 

The  Joint  Staff  and  the  individual  services  are  in  disagreement  “about  the  definition 

of  JSIMS  and  a  plan  of  action”(Dupont,  1995).  Meanwhile  the  Undersecretary  of  Defense 

for  Acquisition  and  Technology  has  chosen  not  to  get  involved  but  rather  to  let  the 

differences  be  solved  over  time. 

‘Further’,  the  report  continues,  ‘the  estimated  $416  million 
in  funding  needed  to  develop  JSIMS  will  be  dependent  upon 
agreement  by  multiple  sources-  the  service  and  other 
agencies.’  In  addition,  DOD  is  ‘uncertain’  how  much  it  will 
spend  to  improve  ALSP  confederation  before  JSIMS  is 
available.  ‘This  uncertainty  raises  questions  as  to  whether 
DoD  is  making  cost-effective  decisions.’  (Dupont,  1995) 

In  the  GAO  report,  $40  million  was  determined  to  planning  for  improving  ALSP 

through  fiscal  year  1999.  It  is  estimated  that  many  of  the  improvements  to  ALSP  will  be 
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finished  at  approximately  the  same  time  that  it  is  scheduled  to  be  replaced  by  JSIMS.  ‘“The 
longer  it  takes  to  make  JSIMS  operational,  the  more  money  DoD  is  likely  to  spend  on  a 
system  that  will  be  ultimately  discarded.’  In  the  meantime,  GAO  states,'the  services  are 
already  developing  their  next  generation  of  training  models  without  a  clear  vision  of  their 
relationship  to  JSIMS,’  which  could  lead  to  duplicate  costs  and  capabilities.”  (Dupont, 
1995)  DoD  only  partially  concurred  with  this  GAO  report. 

D.  GENERAL-PURPOSE  SIMULATION  LANGUAGES 

Simulation  languages  have  increased  in  popularity.  The  use  of  simulation  languages 
is  necessary  for  process  analysis  improvement.  There  are  several  simulation  languages 
available.  These  include  Simscript,  Modsim,  GPSS,  and  Arena.  We  have  chosen  Arena  as 
an  example  of  a  simulation  language. 

It  is  evident  that  the  Navy  has  many  specialized,  high  level  models  and  programs  in 
place.  Each  of  these  models  and  programs  provide  valuable  information  for  logisticians. 
However,  there  exists  a  necessity  for  process  simulation  using  animation.  Process 
simulation  using  animation  adds  a  key  element  to  effective  logistics  planning  and 
management.  That  element  is  communication. 

DoD  no  longer  has  the  luxury  of  large  budgets.  We  cannot  afford  to  spend  money 
on  something  unless  we  are  reasonably  sure  of  its  potential  success.  Simulation  using 
animation  is  necessary  for  “reengineering”  the  way  we  do  business.  It  provides  a  medium 
for  engineers  and  analysts  to  effectively  communicate  plans  and  proposals  to  the  decision 
makers.  The  animation  portion  allows  these  decision  makers  to  actually  view  the  impact  of 
a  logistics  proposal.  For  example,  the  decision  maker  could  see  the  queue  growing  at  an 
intermediate  maintenance  facility  without  having  to  read  through  reams  and  reams  of 
numerical  and  statistical  data  output 

One  of  the  most  flexible,  powerful,  and  easy-to-use  simulation  animation  programs 
is  Arena  developed  by  Systems  Modeling  Corporation.  Arena  can  be  applied  to  any 
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logistics  situation  and  is  very  effective  in  representing  through  animation  the  process  being 
simulated.  Prior  to  releasing  Windows  95,  Microsoft  used  Arena  to  “determine  the  effect 
of  the  higher  volume  of  customer  support  calls.”  The  result  was  customers  waiting  less 
than  two  minutes  to  receive  assistance.  (Ferguson,  1996) 

Arena  is  “a  comprehensive  system  that  addresses  all  phases  of  a  simulation  project 
from  input  data  analysis  to  the  analysis  of  simulation  output  data.”  Systems  Modeling 
Corporation  designed  Arena  to  build  on  the  capabilities  of  Siman  and  Cinema,  two  of  their 
earlier  products.  Arena  allows  a  user  to  easily  and  quickly  model  and  simulate  using 
animation.  This  is  due  to  the  fact  that  Arena  uses  drag-and-drop  and  windows  that  allow 
the  user  to  fill  in  the  blank.  However,  “a  professional  user  can  actually  build  his  or  her  own 
simulation  system  by  combining  Siman  and  Arena  constructs  into  modules  for  the  end- 
user.”  (Hammann,  1995) 

Some  of  Arena’s  applications  are  manufacturing,  logistics,  transportation, 
warehousing,  and  process.  (Ferguson,  1996)  However,  Arena  can  be  tailored  to  any 
specific  application  area.  Arena  could  be  tailored  to  any  logistics  area.  It  could  be  tailored 
to  simulate  a  ship  refueling,  supply  offload,  or  an  aviation  maintenance  plan,  just  to  name  a 
few. 

As  stated  earlier.  Arena  could  be  tailored  to  fit  any  area  of  logistics.  In  this  thesis 
we  have  examined  several  weapons  programs  that  are  ongoing.  Arena  is  a  powerful 
communication  tool  that  could  yield  immediate  results  to  the  program  managers.  Arena’s 
ability  to  simulate  using  animation  would  allow  these  program  managers  to  better 
communicate  the  logistical  details  of  their  program  to  the  decision  makers  in  the  Navy  and 
DoD. 

One  example  of  the  use  of  Arena  would  be  in  the  JSF  program.  Arena  could  be 
used  to  simulate,  using  animation,  the  operation  of  the  common  production  line.  This 
would  allow  the  decision  makers  to  view  the  planned  flow  of  parts  and  equipment  on  the 
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line.  The  workload  of  each  planned  station  of  the  production  line  could  be  viewed.  Arena 
would  also  allow  the  decision  makers  to  view  the  output  of  the  three  aircraft  (USMC, 
USAF,  USN)  of  the  family  of  aircraft.  The  animation  would  communicate  this  production 
line  plan  more  effectively  than  any  other  means  available. 

Additionally,  Arena  would  allow  the  incorporation  of  the  level-of-repair  analysis 
programs  findings  into  an  animation  of  the  repair  plan  for  the  JSF.  Arena  could  model  the 
repair  plan  recommended  by  NRLA,  LORA,  and  JAM.  A  visual  representation  of  the 
maintenance  plan  is  valuable  for  both  the  logistician  and  the  decision  maker.  By  being  able 
to  see  the  projected  maintenance  workload,  the  logistician  for  the  program  could  quickly 
identify  potential  problem  areas  before  the  maintenance  plan  is  adopted.  Arena  would  also 
enable  the  decision  maker  to  witness  the  plan  “in  operation”  well  before  the  maintenance 
plan  is  adopted  and  implemented.  This  will  ultimately  save  time,  money  and  increase  the 
quality  of  logistic  support  for  the  program. 


VI.  SUMMARY,  CONCLUSIONS,  AND  RECOMMENDATIONS 

A.  SUMMARY 

As  Defense  budgets  continue  to  decline,  computer  modeling  and  simulation  use  will 
rise.  Computer  modeling  and  simulation  is  a  cost  effective  way  to  conduct  analysis  and 
influence  program  designs  toward  the  most  effective  and  economical  design  from  a  logistic 
perspective.  While  this  thesis  provides  a  Navy  logistician  with  some  insight  into  modeling 
and  simulations,  there  are  changes  occurring  everyday.  Technology  continues  to  advance  at 
a  rapid  pace  and  improvement  in  pc  technology  allow  a  logistician  to  perform  analysis  on 
his  personal  PC  that  would  have  previously  required  mainframe  computers.  It  is  important 
for  the  Navy  logistician  to  stay  informed  about  modeling  and  simulation  developments 
especially  with  the  move  towards  off-the-shelf  technology  uses.  It  is  especially  important 
for  the  Navy  logistician  to  get  involved  early  in  the  development  of  a  system  or  program 
and  use  computer  modeling  and  simulation  assets  to  influence  design  from  the  very 
beginning.  This  will  result  in  not  only  the  most  economical  system  design  but  also  the  most 
supportable  design  over  the  long  term. 

B.  CONCLUSIONS 

-There  are  many  specialized  computer  models  and  programs  in  DoN  but  there  exists 
a  necessity  for  process  simulation  using  animation. 

In  DoN,  we  do  not  take  advantage  of  process  simulation.  We  have  many  specialized 
computer  models  and  programs,  some  of  which  have  been  discussed  in  this  thesis.  These 
include  LORA,  JAM,  and  ELM.  While  these  programs  provide  excellent  information,  they 
are  not  process  simulations.  Process  simulations  will  provide  an  excellent  communication 
and  evaluation  and  analysis  tool  for  a  logistician. 

-  The  ultimate  user  of  computer  modeling  and  simulations  is  not  being  involved  in 
the  acquisition  decisions  resulting  in  purchases  being  made  of  incorrect  hardware 
or  software. 
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The  Department  of  Defense  has  a  golden  opportunity  to  set  up  a  simplified  management 
structure  right  now.  The  FT96  DoD  Authorization  Act  has  removed  some  cumbersome 
legislation  in  the  area  of  information  technology.  The  main  highlight  is  the  repeal  of  the 
Brook’s  Act.  However,  if  we  in  DoD  do  not  show  Congress  that  we  can  manage  ourselves 
in  this  arena,  legislation  similar  and  possibly  more  restrictive  than  the  Brook’s  Act  will  be 
put  in  place.  User  involvement  in  the  process  of  ADP  acquisition  is  missing.  Also,  users 
are  not  educated  in  the  process  and  their  is  a  “user  and  buyer  disconnect”.  (Stone,  1996) 

-The  Navy  modeling  and  simulation  office  is  unable  to  effectively  mange  computer 
modeling  and  simulation  within  the  Department  of  the  Navy  due  to  the 
organizational  structure  of  computer  modeling  and  simulation  management  in  the 
Department  of  the  Navy. 

Computer  modeling  and  simulation  is  being  used  widely  in  the  Department  of  Defense  and 
the  Department  of  the  Navy.  However,  determining  the  payoff  is  very  difficult  because  of 
the  bureaucratic  management  structure.  We  must  learn  to  manage  computer  modeling  and 
simulation  more  effectively  if  it  is  going  to  pay  the  dividends  we  need  it  to  in  the  future. 

-  Simulations  and  models  must  lean  toward  the  ability  to  perform  joint  functions. 
More  acquisition  programs  are  joint  programs  due  to  the  decreasing  defense  budgets.  With 
decreasing  budgets,  money  is  not  available  to  update,  correct,  and  maintain  numerous 
computer  models. 

C.  RECOMMENDATIONS 
We  recommend  that: 

-DoN  promote  the  use  of  process  simulation  using  animation  (eg..  Arena)  for  all 
logistics  programs. 

While  the  models  and  simulations  we  currently  have  provide  essential  information,  they  are 
also  very  specialized.  The  information  then  must  be  provided  to  the  decision  maker  for  the 
program.  Process  simulation  using  animation  provides  an  excellent  tool  for  communicating 
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a  logistics  plan  to  the  decision  maker.  Communication  is  the  key.  Animation  provides  a 
concise  way  to  communicate  a  logistics  plan  and  also  allows  for  sensitivity  analysis.  The 
ease  of  use  of  process  simulations  such  as  Arena  is  an  additional  plus. 

-Reorganize  the  management  structure  of  computer  modeling  and  simulations. 
Move  the  Navy  Modeling  and  Simulation  Office  to  the  Secretary  of  the  Navy  level, 
specifically  the  Assistant  Secretary  of  the  Navy  for  Research,  Development  and  Acquisition 
Office,  in  order  to  provide  more  influence,  visibility,  and  say  in  budgetary  matters.  Direct 
that  the  Navy  modeling  and  simulation  office  define  what  will  be  considered  and  “model” 
and  what  will  be  considered  a  “simulation”.  Additionally,  DoN  direct  that  the  Navy 
Modeling  and  Simulation  Office  control  the  funding  for  computer  modeling  and  simulations 
within  DoN  and  all  functional  area  managers  will  report  to  the  office  on  modeling  and 
simulation  matters  and  receive  their  funding  for  modeling  and  simulation  from  the  office. 

-The  Navy  Modeling  and  Simulation  Office  reestablish  Team  Mike,  using  video 
teleconferencing  if  necessary  to  reduce  travel  expenses. 

This  will  get  the  users  involved  in  the  process  and  educate  them.  Additionally,  this  will 
ensure  that  the  leaders  and  managers  of  Navy  modeling  and  simulation  are  hearing 
unfiltered  feedback  from  the  users  in  the  fleet. 

-DoN  conduct  a  thorough  study  of  the  current  ADP  acquisition  laws  and  regulations 
and  influence  the  simplification  and  elimination  of  them  where  necessary  to  keep  up 
with  the  fast-paced  changes  in  technology. 

In  some  cases,  rules  and  regulations  prevent  the  purchase  of  necessary  computer  hardware 
or  software.  In  other  cases,  theses  same  rules  and  regulations  result  in  the  purchase  of 
more  expensive  hardware  or  software  because  purchase  of  the  less  expensive  items  is 
disallowed.  Many  of  these  wastes  of  money  could  be  eliminated  through  the  use  of 
common  sense.  Rules  and  regulations  that  no  longer  make  sense  or  have  outlived  their 
usefulness  given  the  fast  pace  of  technology  should  be  eliminated. 
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-Ensure  budgeting  for  computer  modeling  and  simulation  within  DoN  is 
incorporated  within  the  POM. 

If  modeling  and  simulation  is  to  be  a  high  priority  for  the  Navy,  it  must  be  in  the  POM. 
There  is  a  lot  of  truth  to  the  belief  that  if  you  are  not  in  the  POM,  you  do  not  exist.  Money 
needs  to  be  available  for  correcting,  updating,  modifying,  and  maintaining  our  computer 
models  and  simulations  to  ensure  we  are  receiving  the  best  product  for  our  taxpayer  dollar. 


APPENDIX.  POINTS  OF  CONTACT 


This  appendix  contains  a  list  of  the  main  points  of  contact  used  in  this  thesis.  Their 

names,  phone  numbers,  and  electronic  mail  address  is  listed  if  available.  The  information 

contained  herein  is  intended  to  assist  others  interested  in  conducting  follow-on  research. 

1.  DMSO:  Steve  Stamer,  phone:  703-824-3429, 
email:sstamer@msis.dmso.mil 

2.  Office  of  the  Secretary  of  Defense:  Capt.  Bury  (USN),  phone:  (com)  703-695- 
4813,  (a/v)  225-4813,  fax:  703-614-3424,  email:  BurySJ@acq.osd.mil 

3 .  Navy  M&S  Office:  Capt.  Jay  Kistler  (USN),  phone:  703-695-8206 

4.  SPA  WAR:  Mr.  George  Phillips:  phone:  703-69S8206,  email:  phillipg@smtp- 
gw .  spawar.  navy.mil 

5.  CAD;  preliminary  submarine  design:  Mr.  Mark  Henry,  phone:  703-602-5083 
Mr.  Frank  Burkeen,  phone:  703-^2-5607,  email: 
Burkeen_Samuel@hq.navsea.navy.mil 

6.  CAD;  SC-21:  Mr.  Rick  Zebrowski,  phone:  703-602-2151  ext.  207,  email: 
zebrowski_rick@hq.  navsea.  navy,  mil 

7.  JSF:  LCDR  Tom  Hamman,  phone:  703-602-7390  ext.  6632,  email: 
hammantr@ntrprs.jast  mil 

8.  JAM:  NAS  PAX  River,  Mr.  Randy  Barthlett,  phone:  (com)  301-342-4262  (a/v) 
342-4262 

9.  JLSC:  Mr.  Rich  Moore,  phone:  (com)  513-255-3320  (a/v)  785-3320,  email: 
rchmoore@jlsc.wpafb.af.mil 

10.  LORA  (USN):  NAVSEALOGCEN,  Mr.  Russ  Jenkins,  phone:  717-790-4509, 
email:  russel_dJenkins@nslc.fmso.navy.mil 

1 1 .  COMPASS  (USA):  LOGSA,  Army  LORA  Support  Office, 

Mr.  Christopher  Booth,  phone:  (a/v)  645-9838,  email: 
cbooth@logsaemh2.army.mil 

12.  NRLA  (USAF):  Mr.  Rich  Lamb,  phone:  513-255-2122  ext.  580 


45 


LIST  OF  REFERENCES 


Alexopoulos,  C.,  and  others,  1995  Winter  Simulation  Conference  Proceedings,  p.9. 
Winter  Simulation  Conference  Board  of  Directors,  Arlington,  VA,  1995. 

Brake,  F.  B.,  and  West,  E.  A.,  “CALS  at  Work  in  Newport  News  Shipbuilding”,  CALS 
Journal,  pp.  48-56,  Fall  1992. 

CALS  Internet  Homepage,  http://www.cme.nist,gov/nipde/orgs/cals.html. 

COMPASS  User’s  Manual,  USAMC  Logistics  Support  Activity,  Redstone  Arsenal,  AT., 
March  1994. 

DMSO  Internet  Homepage,  http://www.dmso.mil. 

Doragh,  S.  H.,  The  o/JAM/or  LO/?A,  Naval  Aviation  Maintenance  Office, 

Patuxent  River,  MD,  12  May  1995. 

Dupont,  D.  G.,“GAO  Faults  Pentagon’s  Joint  Simulation  System  Development”,  Inside 
the  Pentagon’s  Inside  the  Army,  v.7  no.  45,  pp.l,  10-11,  13  Nov  1995. 

ECRC  Internet  Homepage,  http://www.ecrc.gmu.edu/definition/cals-define.html. 

Ferguson,  G.  A.,  “Buyer’s  Guide,  Simulation  Software,”  Industrial  Engineering 
Solutions,  pp.  54-63,  May  1996. 

Fields,  P.,  MN  3374  course  lecture.  Naval  Postgraduate  School,  9  Jan  ,  1996. 

Goodman,  G.  W.,”Joint  Strike  Fighter” ,  Armed  Forces  Journal  International,  Feb  1996. 

Hamman,  T.  R.,  CDR,  USN,  Joint  Academic  Logistic  Management  Evaluation  (JALME) 
brief.  Naval  Postgraduate  School,  Monterey,  CA,  3  Aug  1995. 

Hamman,  T.  R.,  JSF  Program,  electronic  mail,  15  Mar  1996. 

Hammann,  J.  E.,  and  Markovitch,  N.  A.,  “Introduction  to  Arena”,  1995  Winter 
Simulation  Conference  Proceedings,  p.  519-523,  Dec  1995. 

Holzer,  R.,  “Pentagon  Cuts  DMSO  Funds”,  Defense  News,  v.ll  no.l,  p.l6,  08-14  Jan 
1995. 

Innovation  Business  Services  Internet  Homepage, 
http://fox.nstn.ca/~cottier/overview/CALS/cals.html. 

Interview  between  M.Stone,  Assistant  Professor,  Naval  Postgraduate  School,and  author, 
Monterey,  CA,  22  Feb  1996. 

Interview  (phone)  between  R.Zebrowski,NAVSEA  03H12  (arrcingements  design  division 
for  auxiliary  and  amphibious  ships), Washington,  D.C.,  and  author  14  Feb  1996. 


47 


Interview  (phone)  between  M.  Henry,  NAVSEA  03U  (sub  design  and  system 
engineering), and  author,  31  Jan  1996. 

Interview  (phone)  between  F.  Burkeen,  NAVSEA  preliminary  submarine  design,  and 
author,  5  Feb  19%. 

Interview  (phone)  between  J.Kistler,  Director  of  Navy  Modeling  and  Simulation, 
Washington,  D.C.,  and  author,  30  Jan  1996. 

McMasters.  A.  W.,  Trip  Report  for  31  August  to  4  September  1992. 

Moore,  R.,  Joint  Logistics  Systems  Center,  electronic  mail,  5  April  1996. 

Naval  Sea  Systems  Command  (NAVSEA)  Level  of  Repair  Analysis  (LORA)  Procedures 
Manual,  December  1990. 

Network  Repair  Level  Analysis  Model  User’s  Guide,  ASC/ALTD,  Wright  Patterson  AFB, 
OH,  June  1995. 

Phillips,  G.,  Office  of  the  Director  of  Navy  Modeling  and  Simulation,  N6M1,  electronic 
mail,  31  Jan  and  7  Feb  19%. 

Piplani,  L.  K.,  J.  G.  Mercer,  and  R.  O.  Roop,  Systems  Acquisition  Manager’s  Guide  for 
the  Use  of  Models  and  Simulations,  Defense  Systems  Management  College  Press,  Fort 
Belvoir,  VA,  1994. 

Sherman,  J.,  “New  Office  takes  lead  as...”.  Inside  the  Pentagon’s  Inside  the  Army,  v.7 
no.  45,  pp.l,  10-11,  13  Nov  1995. 

Willis,  C.  I.,  The  Brooks  Act,  Is  It  Relevant  Today?,  Master’s  Thesis,  Naval  Postgraduate 
School,  Monterey,  CA,  Jun  1994. 


48 


INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center . 2 

8725  John  J.  Kingman  Rd.,  STE  0944 

Ft.  Belvoir,  VA  22060-6218 

2 .  Dudley  Knox  Library . 2 

Naval  Postgraduate  School 

411  Dyer  Rd. 

Monterey,  California  93943-5101 


3.  Defense  Logistic  Studies  Information  Exchange . 1 

U.S.  Army  Logistics  Management  College 

Fort  Lee,  Virginia  23801-6043 

4.  Professor  Keebom  Kang,  Code  SM/KK . 4 

Department  of  Systems  Management 

Naval  Postgraduate  School 
Monterey,  California  93943-5103 

5.  Donald  R.  Eaton  RADM  (Ret),  Code  SM/ET . 4 

Department  of  Systems  Management 

Naval  Postgraduate  School 
Monterey,  California  93943-5103 

6.  Professor  Carlos  Borges,  Code  MA/BC . 1 

Department  of  Mathematics 

Naval  Postgraduate  School 
Monterey,  California  93943-5000 

7.  Robert  B.  Scearce  II . 2 

219  Annhurst  Dr. 

Danville,  Virginia 24540 


